home *** CD-ROM | disk | FTP | other *** search
- Path: galaxy.ucr.edu!not-for-mail
- From: thp@cs.ucr.edu (Tom Payne)
- Newsgroups: comp.programming.threads,comp.lang.c++,comp.unix.osf.osf1,comp.unix.programmer,comp.object
- Subject: Re: Looking for best design for using pthreads in C++ objects
- Followup-To: comp.programming.threads,comp.lang.c++,comp.unix.osf.osf1,comp.unix.programmer,comp.object
- Date: 8 Mar 1996 18:39:04 GMT
- Organization: University of California, Riverside
- Message-ID: <4hpus8$ld6@galaxy.ucr.edu>
- References: <3128ff8b.666031216@news.clark.net> <312A0E5F.7B2C@ix.netcom.com> <31320705.41C6@zko.dec.com>
- NNTP-Posting-Host: corvette.ucr.edu
- X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
-
- Webb Scales (scales@zko.dec.com) wrote:
- : David Brownell wrote:
- : > One of the really nice techniques is to have a "Locker" class to grab mutexes
- : > as needed, and then release it automatically on all exits. [...]
- : > That kind of class really helps get rid of the bugs you have due
- : > to locks not getting released uniformly on all codepaths.
- :
- : For instance, if a thread holding a mutex via the "Locker" class terminates
- : prematurely (due to an exception or cancellation), then the mutex will be
- : unlocked automagically, despite the fact that whatever it was supposed to
- : protect is now likely to be in an inconsistent state.
-
- Good point. In my use of Lockers, I always pass a pointer to the surrounding
- (monitor) object so that the Locker can find and acquire the local lock, e.g.,
-
- Locker exclusion(this);
-
- Thus, the Locker's destructor can assert the monitor's invariants or
- check them and attempt to tidy up. What I'd really like is a way for
- my destructor to know that it is being called through the processing
- of an exception and to have access to that exception object.
-
- Tom Payne (thp@cs.ucr.edu)
-